A typical characteristic of cloud computing environment is “commonality”. This characteristic ensures that the same piece of “cloud” can support a normal operation of an application at any physical location and with any configuration combination in the cloud environment, thus achieving the purpose of flexibly configuring and managing the application.
Currently, a stateless use of resource is advocated in the cloud computing environment. Therefore, relevant researchers have proposed a stateless virtual machine. A main design concept of the stateless virtual machine is to partition the virtual machine into an OS (operating system) image file and an application data service image file.
FIG. 1 shows an exploded schematic view of a conventional stateless virtual machine. As shown in FIG. 1, an OS.qcow2 file existing in the physical system disc corresponds to the operating system and is an OS image file which can be responsible for running the operating system and installing common software (e.g., JDK, Jboss, etc.); an data.qcow2 file existing in the physical data disc corresponds to the application data service image file and can store running code, configuration file, log and service data of the application itself. The object of such a design is to hope that the application can run normally after any combination of any data disc with other system discs, without being limited by the restrictions of the operating system disc. Meanwhile, the OS image file will be used as a template image, the newly created virtual machine usually reproduce the template image as a basis, and dynamically creates an empty file as a data service image.
While the stateless virtual machine shown in FIG. 1 can directly run a Java program in a simple application scene, the goal of separating and decoupling the application from the system can be obtained. However, there are many difficulties with a complicated scene having an application middleware. Existing technical solutions of stateless virtual machine having an application middleware mainly have two structures shown in FIGS. 2 and 3.
FIG. 2 is a schematic view showing the module structure of a stateless virtual machine according to an embodiment in the prior art. As shown in FIG. 2, the stateless virtual machine 10 mainly comprises an OS image file 11 and an application data image file 13 that are placed separately, and further comprises an application middleware 15, wherein the application middleware 15 is entirely stored in the OS image file 11 of the corresponding operating system. Specifically, a middleware program (i.e., a middleware core 151 of the application middleware 15) and relevant configuration (i.e., a middleware configuration 153 of the application middleware 15) are stored in the OS image file 11, and application codes and relevant data (i.e., application data) are stored in the application data image file 13. In the stateless virtual machine in this embodiment, the operating system and the middleware are in the same physical storage disc, i.e., in the same one OS image file. Although the solution of the stateless virtual machine in this embodiment facilitates producing a uniform template image, the middleware configurations 153 are actually personalized and differentiated for different application, this is because the middleware configuration 153 has an associated relationship with the application 131 of the application data image file 13, e.g., the start configuration parameter of the application 131, etc. As such, when the application data image file 13 is combined with another OS image file 11, the application cannot be started normally since the middleware configuration 153 does not match with the application 131.
FIG. 3 is a schematic view showing the module structure of a stateless virtual machine according to another embodiment in the prior art. As shown in FIG. 3, the stateless virtual machine 20 mainly comprises an OS image file 21 and an application data image file 23 that are placed separately, and further comprises an application middleware 25, wherein the application middleware 25 is entirely stored in the application data image file 23. Therefore, the application 231 and the application middleware 25 are both stored in the application data image file 23. It is understood that essentially the OS image file 21 is merely a highly standardized operating system. In the stateless virtual machine in this embodiment, since the application data image file 23 contains all the configurations related to application personalization (i.e., the middleware configurations 253), it can be used in combination with any other standardized OS image file 21 and the problem of the virtual machine in the embodiment shown in FIG. 2 is overcome.
However, even the framework features of the virtual machine in the embodiment shown in FIG. 3 also greatly reduce the efficiency in disposing applications by the data center. This is because: firstly, the OS image file (template image) 21 does not contain the application middleware 25; therefore, each time a virtual machine is newly generated, it is required to reinstall the application middleware 25 and the application 231 in the application data image file 23 (since the application data image is initially an empty disc space), and as compared to a situation in which the OS image file (template image) has an installed application middleware (the embodiment shown in FIG. 2), it is merely required to re-dispose the application in FIG. 2, and the complexity in disposing the application in the embodiment shown in FIG. 3 is greatly increased; secondly, since the automatic application starting service is often associated in the operating system, the operating system cannot locate the application middleware 25 since the application middleware 25 is not installed in the disc (i.e., the OS image file 21) in which the operating system is located, thus making it impossible for the application to start automatically after the virtual machine restarts.
Therefore, the framework features in the prior art stateless virtual machine using an application middleware lead to various problems, and make it hard to balance between the efficiency and the personalized configurations.